NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/7756

Text File | 1996-08-05 | 5.1 KB | 124 lines

Newsgroups: comp.lang.c
Path: news.sprintlink.net!eskimo!scs
From: [e-mail] (Steve Summit)
Subject: Re: Using char array in functions
X-Nntp-Posting-Host: eskimo.com
Message-ID: <[e-mail]>
Sender: [e-mail] (News User Id)
Organization: schmorganization
References: <[e-mail]> <4gqk5m$[e-mail]>
Date: Wed, 28 Feb 1996 18:48:16 GMT

In article <4gqk5m$[e-mail]>, [e-mail] (Ed Toivanen)
writes:
> In article <[e-mail]>,
> [e-mail] says...
>> I've searched the faq's and postings, but still am looking for
>> a clear explanation on how to use arrays of char strings in
>> functions, especially when I want to have the function modify
>> the array.  I find I can't just pass the
>> name of the string as a pointer as I do for single strings.
>  ^^^^
>
> As I just learned from my midterm(the hard way, in other
> words!) you have to pass the address of the name of the array
> if you expext to modify more than a copy of the thing.

Huh?  Either taylor@sundog, or Ed Toivanen, or I, or some
combination of us is/am/are confused.  (I'm so confused I can't
even figure out what verb to use!)

C doesn't use pass-by-name, so let's not use this word "name."
C does use pass-by-value, which means that functions receive
copies of their actual arguments, which means that functions
cannot modify their arguments and have those modifications
reflected in values in the caller, with the possible exception of
arrays.  Superficially, it looks as if a function which modifies
an array which has been passed to it *does* modify the array in
the caller, and it's not a bad rule to remember that arrays are
an exception to the rule that functions operate on local copies
of their arguments (or, stated another way, that arrays are an
exception to the rule that functions can't modify the values in
the caller which it passed as arguments).

The word "superficially" in the previous paragraph appears there
because it's not strictly true that a function can modify an
array which was passed to it.  It can indeed modify the array in
the caller, but what was passed to the function was not the
array, but rather a pointer to the array's first element.
When you look at it that way, there's no exception to the
call-by-value rule: a function receives a copy of its pointer
argument, and it could only modify that copy of the pointer, but
it can certainly *use* that pointer (without even modifying it)
to modify what it *points to*, namely something in the caller.

A canonical example is the function getline:

    char line[100];
    int len = getline(line, 100);

This hypothetical (or see K&R for concrete examples) getline
function returns two things: the length of the line it reads (as
its formal return value), and the contents of the line it reads,
which it "returns" by writing it into what appears to be its
array argument.  (Another way of thinking about the situation is
that getline's first argument tells getline where to write the
line.)

It is perfectly legal, quite possible, and most common for a
function to modify an array which seems to have been passed to it
(usually by mentioning the array's name in the function call
argument list).  The only time this wouldn't work would be if the
array were not modifiable, either because it was declared const
or because it is a string literal.  The call to getline above
would work, but these three might not:

    const char constline[100];
    len = getline(constline, 100);

    char *p = "Hello, world!";
    getline(p, 100);

    getline("Hello, world!", 100);

These calls would not work because, again, the arrays are not
modifiable.  It is hard to imagine a situation in which a
function was unable to modify what appeared to be an array
parameter for the reason that it was operating on a copy of the
array.  (The only way I can imagine this failure mode is if the
array is wrapped up in a struct, and in that case the function
would no longer appear to be receiving an array parameter; it
would be receiving a struct parameter.)

Finally, as we've just been discussing in another thread, you
don't need (and, in fact, rarely want) an explicit "address of"
operator & when you're passing a pointer down to a function so
that the function can modify one of your arrays.  When you write

    getline(line, 100)

it's as if you had written

    getline(&line[0], 100)

and it's that implicit & which generates the pointer that getline
actually receives (or, speaking more strictly still, that getline
receives a copy of).  If you were to write

    getline(&line, 100)

it would be incorrect, because getline would receive a pointer-
to-array-of-char instead of the pointer-to-char it expects.
(Since, on most machines, these two types are likely to have the
same sizes and representations, and for the same array to have
the same values, the incorrect call involving &line is likely to
work, but for the wrong reason.)

                    Steve Summit
                    [e-mail]
--
The Communications Decency Act within the Telecommunications Act
of 1996 (U.S.) is an annoying, threatening, abusive, indecent,
and obscene piece of legislation which attempts to ban annoying,
threatening, abusive, indecent, or obscene communication.